REMARKS 

Claims 1-42 are pending in the present application. Reconsideration of the claims 
is respectfully requested. 

I. 35 U.S.C. § 102, Anticipation 

The Examiner rejected Claims 1-42 under 35 U.S.C. § 102 as being anticipated by 
U.S. Patent No. 6,012,086 (Lowell). This rejection is respectfully traversed. 

The present invention is generally directed to an enhanced technique for a user to 
request a media data stream, convert the media data stream into a desired format and then 
store the formatted media data stream. By allowing the user to convert the media data 
stream into a desired format, the prior requirement to have an appropriate media player 
for each different type of media format that may be received is eliminated. This is 
particularly advantageous when there exists a multiplicity of different media formats as 
exists today, such as MPEG-2, MPEG-3, MPEG-4, M-JPEG, Realvideo and AVI. The 
cited reference provides no ability for the user to pre-specify a format for use in 
converting a received media stream. 

Specifically with respect to Claim 1, such claim recites "receiving user input for 
use in managing the media data stream, wherein the user input includes an identification 
of a source of the media data stream, a start time, and a desired format ", and "converting 
the media data stream into the desired format " (emphasis added by Applicants). In 
rejecting Claim 1, the Examiner states that Lowell teaches a user input specifying a 
desired format at column 6, lines 22-46, and that Lowell teaches converting the media 
data stream into the desired format is taught by Lowell column 8, lines 35-50. Applicants 
show error in such assertion as follows. 

Lowell states at column 6, lines 22-46: 

FIG. 4 illustrates a representative Internet event recorder dialog box. 
Internet event recorder dialog box 400 includes several fields which allow 
the input of data by the user through an input device. The first field 404 is 
the source URL field. In this field the user types the URL or Internet 
address for the web site of the server which is providing the data to be 
recorded. Field 406 is the date field in which the user types the date on 
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which the event is to be recorded. The date may be specified as a single 
day if a single event is to be recorded; or the date may be specified as a 
range of dates (e.g., "1/1 to 1/5") or selected days (e.g., "every day" or 
"every Saturday") if a recurring event is to be recorded. In field 408, the 
user inputs the start time at which the recorder is to start recording, and 
in field 410 the user enters the stop time which is the time at which the 
recording is to be stopped. Alternatively, field 410 may be programmed 
with the duration of the recording session starting from the start time (e.g., 
+2 hours). The time parameters can be entered in standard 12-hour clock 
format with a.m. or p.m. indicators, or alternatively they can be entered in 
24-hour format. Additional parameters which may be programmed into the 
time fields include an adjustment for time zone variations and automatic 
correction for daylight savings time (e.g., if the client and the server 
computers are located in different time zones). 

Lowell goes on to describe other user-specified fields pertaining to the user-interface 
shown in Figure 4, including a field 412 that provides for entry of an optional macro or 
program routine for program entry of such things such as control keys, a network 
subaddress of a userlD or accesss code (column 6, lines 45-52); and a field 414 where a 
user enters the destination for the data stream or file (column 6, lines 63-65). As can be 
seen, Lowell teaches a source and destination location for retrieving and storing a file, as 
well as the start and stop time for recording. Notably, Lowell does not teach any field for 
allowing a user to specify a desired format, as expressly recited in Claim 1. This desired 
format is shown in the preferred embodiment at Figure 5A, elements 524, 526 and 528. 
This desired format is in addition to other user-specified fields such as input and output 
location (elements 522 and 530) and the start and stop times (elements 518 and 520). 

As to the cited Lowell passage at column 8, lines 35-50 - purporting to teach the 
claimed step of converting the media data stream into the desired format - Applicants 
urge that such passage describes that audio or video data may be made available by the 
server in several different formats, thus requiring the web browser to determine the 
format in which the data is available (column 8, lines 40-42). There is simply no 
teaching that the data as provided on the server in a particular format is converted to a 
user-specified format. Rather, this is exactly the type of situation that the present 
invention overcomes. Instead of requiring the user data processing system to support a 
plurality of dissimilar media formats - in this case Lowell's web browser - the present 
invention provides user specification of a desired format such that a plurality of 
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dissimilar formats do not have to be provided for in the user data processing system (as is 
required by the Lowell system). 

As every element of the claimed invention is not identically shown in a single 
reference, it is shown that Claim 1 is not anticipated by the cited reference. 

Applicants initially traverse the rejection of dependent Claims 2-16 for reasons 
given above with respect to Claim 1 (of which Claims 2-16 depend upon). 

Further with respect to Claim 7 (and dependent Claims 8 and 9), such claim 
recites "identifying an initial format of the media data stream; converting the media data 
stream to a viewable format; and converting the media data stream to the desired format 
from the viewable format". As can be seen, this claim is directed to a two-pronged 
conversion. The first prong of this conversion is directed to converting the media data 
stream to a viewable format. The second prong of this conversion is directed to 
converting the media data stream to the (user-specified) desired format from the viewable 
format. The cited reference does not teach such two-pronged conversion. In rejecting 
Claim 7, the Examiner cites Lowell column 8, lines 35-50 and column 9, lines 40-50 as 
teaching all the converting steps recited in Claim 7. Applicants show error, as the Lowell 
passage at column 8 does not teach any type of conversion, but rather teaches that a web 
browser determines the format that the data is available. The Lowell passage at column 9 
states that in order to access and playback the data, it is typically necessary for the user to 
execute the same programs or plug-ins that are required when accessing the data directly 
from the server (column 9, lines 37-40). This passage does not teach or otherwise 
suggest converting a file to an intermediate format (the claimed viewable format) and the 
converting from this intermediate format to a (user-specified) desired format. IN fact, 
this passage establishes that no conversion occurs at all, as the same program or plug-in 
used to receive the data is required to subsequently access the data - which clearly 
establishes that the data has not been converted to another format otherwise this 
requirement for the same program/plug-in would not exist. This further establishes that 
Claim 7 (and dependent Claims 8 and 9) is not anticipated by the cited reference, as there 
are additional claimed steps not taught by the cited reference - including the two-pronged 
conversion prior to storing. 
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Still further with respect to Claim 8 (and dependent Claim 9), such claim recites 
'Svherein a set of codecs are used to convert the media data stream from the initial format 
to the viewable format and to convert the media data stream from the viewable format to 
the desired format". In rejecting Claim 8, the Examiner states that this claimed feature is 
taught by Lowell at column 9, lines 40-50 (the decryption and decompression programs). 
Applicants show error in such assertion, as the decryption and decompression as taught 
by the cited passage is with respect to data processing after the program has been locally 
stored and is subsequently being played back. In contrast, Claim 8 (which depends upon 
Claim 7 which itself depends upon Claim 1) is with respect to processing prior to storing 
the data (per Claim 1, converting ... to form a formatted media data stream and storing 
the formatted media data stream on a storage media, where the converting step includes 
use of the set of codecs as recited in Claim 8). The Lowell teaching of decryption and 
decompression after storing data does not teach the claimed use of a set of codecs as a 
part of a converting step prior to storing the formatted media data stream, as recited in 
Claim 8 (in combination with Claim 1 and 7). Thus, Claim 8 (and dependent Claim 9) is 
further shown to not be anticipated by the cited reference. 

Further with respect to Claim 10, such claim recites "wherein the desired format 
is an audio format and the media data stream includes video and audio and further 
comprising converting only audio portions of the media data stream into the audio 
format". In rejecting Claim 10, the Examiner cites Lowell column 5, lines 22-30 as 
teaching this claimed feature as Lowell discloses that the media data stream contains both 
audio and video data but formatting done appropriately for the radio in Figure 3 to play 
the audio format, "wherein clearly this radio is only capable of playing the audio data and 
hence would only convert the audio data". Because the cited passage does not expressly 
teach this claimed feature of both audio and video data, but converting only the audio 
data, the Examiner appears to be taking the position that this is inherent in the teachings 
of Lowell. Applicants urge that this feature is not inherent. "To establish inherency," the 
Federal Circuit recently stated, "the extrinsic evidence "must make clear that the missing 
descriptive matter is necessarily present in the thing described in the reference, and that it 
would be so recognized by persons of ordinary skill. 1 " In re Robertson, 169 F.3d 743, 745 
[49 USPQ2d 1949] (Fed. Cir. 1999); see also Continental Can Co. U.S.A., Inc. v. 
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Monsanto Co., 948 F.2d 1264, 1268 [20 USPQ2d 1746] (Fed. Cir. 1991). Such inherency 
may not be established by "'probabilities or possibilities/" Continental Can, 948 F.2d at 
1269 (quoting//! re Oelrich, 666 F.2d 578, 581 [212 USPQ 323] (C.C.P.A. 1981)). The 
passage cited by the Examiner describes an on-line radio application, and then goes on to 
state alternative applications where a web page may provide access to any type of 
multimedia content. In this alternative scenario, the event might contain both audio and 
video. This is an alternative application and is not with respect to the radio shown in 
Figure 3. Rather, it states that "the web browser would need to execute the appropriate 
viewing software to display the program or event". This does not in any way establish 
that only audio portions are converted - the passage expressly recites the use of viewing 
software to display the video data. Thus, Claim 10 is further shown to not be anticipated 
by the cited reference. 

With respect to Claims 15 and 16, Claim 15 recites a control to select a format for 
storing data, and Claim 16 recites a control to select a location to store data. Remarkably, 
the Examiner cites a single passage and element as teaching both of these controls. 
Specifically, the Examiner states that both of these claimed controls are taught by Lowell 
at column 6, lines 63-66. Applicants show that there, Lowell states: 

Field 414 provides a field in which the user enters the destination for 
the data stream or data file. Typically the destination is the name of a 
file which has been created on a hard disk for storage of the data stream or 
file. 

As can be seen, this passage merely describes a single field where a user enters a 
destination for the data stream/file. This single field is not also used to specify or select a 
format for storing data (per Claim 15). Thus, Claim 15 is further shown to not be 
anticipated by the cited reference. 

With respect to Claim 17 (and dependent Claims 18 and 19), such claim recites 
receiving user input selecting the format and the location, and responsive to receiving the 
media data stream, converting the media data stream into the format to form a formatted 
media data stream. The cited reference provides no ability for user selection of a format 
for which the media data stream is converted. In rejecting Claim 17, the Examiner cites 
column 6, lines 23-25 and lines 63-66 as teaching this claimed feature. These passages 
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merely recite a source field for where the data exists (column 6, lines 23-25), and a 
destination field of where the data is to be stored (column 6, lines 63-66). Neither a 
source or destination field as described by Lowell teaches or suggests the claimed user 
selection of a format for converting the data, as recited in Claim 17. Thus, Claim 17 (and 
dependent Claims 18 and 19) is not anticipated by the cited reference as every element of 
the claimed invention is not identically shown in a single reference. 

With respect to Claim 20, Applicants traverse for similar reasons to those given 
above with respect to Claim 1. 

With respect to Claim 21, Applicants traverse for similar reasons to those given 
above with respect to Claim 17. 

With respect to Claim 22 (and dependent Claims 23-37), Applicants initially 
traverse for similar reasons to those given above with respect to Claim 1. 

Further with respect to Claim 28 (and dependent Claims 29 and 30), Applicants 
traverse for similar reasons to the further reasons given above with respect to Claim 7. 

Further with respect to Claim 29 (and dependent Claim 30), Applicants traverse 
for similar reasons to the further reasons given above with respect to Claim 8. 

Further with respect to Claim 31, Applicants traverse for similar reasons to the 
further reasons given above with respect to Claim 10. 

Further with respect to Claim 36, Applicants traverse for similar reasons to the 
further reasons given above with respect to Claim 15. 

With respect to Claim 38 (and dependent Claims 39 and 40), Applicants traverse 
for similar reasons to those given above with respect to Claim 17. 

With respect to Claim 41, Applicants traverse for similar reasons to those given 
above with respect to Claim 1. 

With respect to Claim 42, Applicants traverse for similar reasons to those given 
above with respect to Claim 17. 

Therefore, the rejection of Claims 1-42 under 35 U.S.C. § 102 has been 
overcome. 
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II. Conclusion 

It is respectfully urged that the subject application is patentable over the cited 
reference and is now in condition for allowance. The Examiner is invited to call the 
undersigned at the below-listed telephone number if in the opinion of the Examiner such 
a telephone conference would expedite or aid the prosecution and examination of this 
application. 



DATE: 



// M(a>> 



Respectfully submitted, 

Duke W. Yee 
Reg. No. 34,285 
Wayne P. Bailey 
Reg. No. 34,289 
Yee & Associates, P.C. 
P.O. Box 802333 
Dallas, TX 75380 
(972) 385-8777 
Attorneys for Applicants 
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